Honcho vs llm-wiki Division of Responsibility
替代 Mem0 vs llm-wiki Division of Responsibility（已 SUPERSEDED）。 配套：Honcho、Honcho memory、llm-wiki、Why Honcho over mem0
关键区别
Honcho 跟 llm-wiki 是完全不同的层——回答完全不同的问题：
| Honcho | llm-wiki | |
|---|---|---|
| 回答的问题 | "这个人是谁？怎么决策？" | "这件事怎么做？方法论是什么？" |
| 范围 | 单个 peer 私域 | 团队公共知识 |
| 受众 | Agent（hermes 通过 chat() 工具调） | 人 + Agent 都读（markdown / wiki.86lux.net） |
| 形态 | 内部 reasoning 表征 | 结构化 markdown |
| 编辑 | 不能人工编辑（自动 Dreaming） | 可人工编辑 + git history |
| 审批 | 无 | review gate（drafts → canon） |
| 永久性 | 推理结果可能随新对话漂移 | 钉死在 canon，git 回滚 |
| 对外分享 | API only | 截图 / 链接给客户都行 |
谁在干什么
Honcho（私域用户理解层）
- 存原始对话 + 自动 Dreaming Agent 综合推理
- 给 Hermes 一个"我对当前用户的综合理解"
- 例如：hermes-jingwen 用了 3 个月后真的"懂" jingwen 的决策风格
- LLM-native：输出是自然语言推理结论，不是 fact 列表
llm-wiki（公共团队知识层）
- 把高价值任务结果编译成结构化 markdown
- 去重 / 归纳 / 重写 / 结构化
- 进 wiki.86lux.net 让所有人 + 所有 hermes 都能读
- 永久 + 审批 + git 版本
关键场景对比
场景 1：用户问 "我们之前对蒸汽挂烫机的决策是什么？"
| 谁答 | 答什么 |
|---|---|
| Honcho | "你（jingwen）参与过这个决策，倾向 GO，主要顾虑是品控。" — 主观、私域、给当前用户的 agent |
| llm-wiki | 在 canon/决策/蒸汽挂烫机-决策.md，结论 GO，理由 A/B/C，反对意见 D，决策日期 2026-04-15 — 客观、永久、给所有人 |
两个答案不冲突，是互补的。一个给主观倾向，一个给客观记录。
场景 2：hermes 处理新任务时
1. Hermes 接到飞书消息（任务）
2. → 调 honcho_profile 或 honcho_context 拿"这个用户是谁、之前聊过什么"
3. → 读 wiki canon/ 拿"这种任务的方法论 + 历史决策"
4. → 干活
5. → 干完后，结论值得长期保留就走 wiki-compile 写到 canon/drafts/
6. → 对话过程自动进 Honcho session（Dreaming Agent 后台学画像）工作流规则
| 阶段 | 用 Honcho | 用 llm-wiki |
|---|---|---|
| Hermes 思考 / 干活时 | ✅ 自动注入 user representation | 主动读 canon/ |
| 任务完成 | 自动 ingest 对话进 Honcho | 仅高价值结论手动/Multica 触发 wiki-compile |
| 跨成员协作 | 不允许（铁律） | ✅ 共享 canon/ |
| 对外分享 / 给客户 | 不能 | ✅ 截图 wiki.86lux.net |
哪类内容进哪里
进 Honcho（user-specific）
- 用户偏好（"我喜欢黑色简约设计"）
- 决策习惯（"jingwen 倾向数据驱动决策"）
- 个人节奏（"早上 9-11 点产出最高"）
- 对话上下文 / 任务历史
- 短期工作记忆
进 llm-wiki（public）
- SOP 标准操作流程
- 决策记录（Go/No-Go）
- 方法论 / 框架
- 实体定义（这个品类是什么、这个工具是什么）
- 团队规则
- 历史归档
都不进（仅留在 Chat / Issue）
- 临时调试输出
- 未验证猜测
- 噪音回答
- 一次性的简单问答
常见错误
| 错误 | 危害 | 对策 |
|---|---|---|
| 把 Honcho 当 wiki 用（指望它存稳定决策） | reasoning 会漂，3 个月后查不到原结论 | 重要结论手动走 wiki-compile |
| 把 wiki 当 Honcho 用（试图记每个用户偏好） | canon 变隐私垃圾场，且不更新 | 偏好让 Honcho 自动学 |
| 跨 hermes 共享 user representation | 违反隐私铁律 | hermes-admin 不该读 hermes-jingwen 的 peer |
| 不分场景一刀切 | 同事感受混乱 | 跟着上面"哪类内容进哪里" |
真正的演进方向
长期愿景：Honcho 给 hermes 一个"懂这个用户的助理"，llm-wiki 给团队一个"集体大脑"。两者互不依赖、互相补充：
- 没 wiki，hermes 靠 Honcho 也能继续聊（但失去团队级方法论）
- 没 Honcho，hermes 靠 wiki 也能干活（但失去用户个性化）
- 两者都有：hermes 像一个"懂你 + 懂公司"的资深员工
Final Decision
Honcho 负责理解人，llm-wiki 负责传承事。
它们不是替代关系，是正交两层。